Traditionally, the primary objective of testing systems for communications networks, such as telephony networks, was to verify the integrity and continuity of transport facilities and functions. For example, loop test systems for plain-old-telephone-service are used to make a large number of electrical measurements (e.g., D.C. voltage, A.C. impedance, etc.), perform an extensive analysis of those measurements, and provide an interpretation of those measurements as to whether a subscriber's loop is normal, open, shorted, etc. Also, systems for testing digital networks (e.g. Digital Data System Services (DDS) Integrated Services Digital Network (ISDN)) may entail insertion of a pseudorandom digital data sequence at one access point in the network and analysis of the received sequence for errors when the network is monitored at a second access point.
In traditional communications networks, there were typically limited service offerings, which required only basic processing. Furthermore, service processing typically invoked functions which were centrally located at network nodes. By having processing functions centrally located, testing of processing functions by a craftperson was relatively simple. Given the simplicity of service processing and the fact that processing functions were centrally located, testing of processing functions was not a significant challenge.
With the increased service offerings and complexity of present day communications networks, testing needs have expanded beyond merely testing of transport facilities between network nodes, particularly, in distributed networks. In distributed networks, such as the Advanced Intelligent Network (AIN), service processing functions and operations are geographically distributed at multiple nodes throughout the network. Furthermore, subscriber- and service-specific logic and data, which are invoked by service processing nodes, may also be stored at locations that are geographically distinct from the locations of various processing nodes. Therefore, testing needs of present-day distributed networks, such as AIN service, include not only transport, but also call processing nodes, which are geographically distributed and dependent on subscriber-specific as well as service-specific data. While traditional testing systems for loops, trunks, and signaling links may still be useful for verification of the continuity and integrity of transport facilities and functions of distributed network, testing of service processing in a distributed network has become a challenge.
An approach to testing service processing in a distributed network is to dispatch craft personnel to each processing element or node invoked in providing service to a subscriber and to conduct isolated tests of each node individually. However, this approach could be very labor-intensive, time-consuming, and cost-prohibitive, especially where multiple network nodes are involved, since testing at all nodes may entail the cooperation and coordination of a team of craftpersons. Another drawback is that test results may be disjointed since overall test results are based upon data collected from isolated, unrelated tests conducted at each individual node.
To gain an accurate and continuous view of service processing over a subscriber's line, another approach to testing may be for craft personnel to gain physical access to the subscriber's line and to test the line directly. However, a drawback of this approach is that physical access to the subscriber's communication line may be difficult during normal business hours when non-business subscriber's are most likely to be unavailable. Furthermore, this approach will cause the subscriber's service to be interrupted during testing. In addition, under this approach, verification of service troubles may only be permitted; however, absent the capability to collect test data from individual network nodes, sectionalization of service trouble to particular network nodes may not be possible.
To effectively test for service trouble in a distributed network such as AIN, the following test capability may be needed:
1) To verify service and sectionalize trouble in an economical and timely manner; PA1 2) To test a subscriber's service from the subscriber's perspective without having physical access to the subscriber's line; PA1 4) To generate an end-to-end view of service processing; PA1 5) To log activity between network nodes; and PA1 6) To retrieve logged activity related to service processing for sectionalizing trouble in the network.